This file is a compliation of various bulletins about UO-14 operations. From : g0k8ka To : all Title : Addressing Mail Keywords : PG HEADERS ADDRESSES Uploader : G0K8KA Uploaded : Wed Jan 16 12:26:56 1991 __________________________ BULLETINS - These are messages which would be of interest to many people on the satellite. They should have "ALL" in their destination field. "ALL" must be the first thing in the destination, not preceeded by any spaces. Additional information about the subject of the message should be put in keywords and/or the title field. PRIVATE MAIL - This is a message to a specific station. That station's callsign must appear in the destination field of the file. The callsign must be complete, without any extra spaces or other characters in it. It may be preceeded or followed by other words. The following destinations will show up as mail for G0K8KA: g0k8ka G0K8KA G0K8KA@UOSAT3 G0K8KA.UK.EU.EARTH NK6K+G0K8KA+N4HY g0k8ka The following destinations will not show up as mail for G0K8KA: G0/K8KA gok8ka g0 k8ka Notice that case does not matter. Forther notes on addressing will be provided when necessary. We don't intend to force any particular addressing scheme on the network, but certain conventions must be adhered to. JWW From : g0k8ka To : all Title : PG HINTS Keywords : PG Uploader : G0K8KA Uploaded : Sat Feb 09 12:52:27 1991 __________________________ I am still working on complete documentation for the newest release of PG. In the mean time, if there are any questions, you can direct them to me here on UoSAT-3. - If there is any chance that you will turn MALL ON, you should put a line MALL OFF in your PG.TNC file. This keeps connected mode packets from interfering with the detection of the BBSTAT beacons. - The Serial I/O report at the end of the program should help us diagnose some of the problems which end with "unexpected packet" and the binary rubbish display. Missed interrupts are caused by other interrupt-driven programs (i.e. TSRs keeping interrupts turned off for too long). 4k Buffer overflows are caused when interrupts are enabled (good) but PG is not allowed to run (bad). - The new version has been built with Microsoft C 6.00a, rather than 5.1. I noticed here that the C6.00a video routines interacted strangely with one of our VGA BIOSes. I was able to solve the problem on that specific machine by setting MODE BW80 on the DOS command line. Why? I don't know. If you have persistant problems which might be video problems, you should set the environment variable MONO=ON. This will force PG to work in monochrome mode, which should at least test different portions of your BIOS! - There has been one report of complete crash/burn with the new PG. I suspect that the video drivers are involved in this, but I have no solution. I'll try my best, but all I can do is test it here with our hardware and then ship it! We use a DELL 316 (16 MHz SX) in the groundstation and I use some no-name clone 386DX 20MHz for development. All of our TNCs are PacCom Tiny-2 with TAPR V 1.1.7. It works here! 73, JWW From : g0k8ka Title : Headers, BIDs, and BBSs Keywords : BID PBBS PFHADD PACSAT PROTOCOLS Uploader : G0K8KA Uploaded : Thu Jan 24 12:00:02 1991 __________________________ Please refer to PACSAT File Header Definition. BBS MESSAGE TRANSFERS When we designed the PACSAT Protocol Suite, we attempted to support all imaginable terrestrial bulletin board operations, without forcing any particular scheme of addressing or routing onto the terrestrial operators. Nevertheless, it is important that terrestrial BBS operators use the PACSAT Protocols in an efficient manner which takes full advantage of available features. The PACSAT Protocol Suite supports bulletin-board file transfers in two ways: (1) a single BBS message can be transferred in a single PACSAT file, (2) multiple BBS messages can be transferred as one PACSAT file. For each of these methods, there is an appropriate PACSAT file type. File type 0x01 is for a single message, and file type 0x02 is for multiple messages. We expect that multiple messages will be transferred in the RLI/MBL standard export format. If other formats are to be used, further file types will be assigned. The advantage of using a unique FILE_TYPE for such files is that groundstation software can use the PACSAT SELECT command to select only BBS-type messages, and ignore all others. This will be useful when PACSAT BBS gateway software is implemented. Please use the proper FILE_TYPE when uploading BBS messages to PACSAT. If you believe that additional file types are needed, contact NK6K or G0K8KA. (Eventually, this will be handled by AMSAT operations crew members, but for now the developers will keep a hand in the assignments.) BULLETIN IDs The use of BIDs is related to BBS traffic, but should not be restricted to BBS traffic. I guess that every message to "ALL", which might be downloaded and inserted into the terrestrial BBS network, should have a BID. The BID should NOT be placed in the text; it should be in the PACSAT File Header, where an appropriate item id (0x21) has already be defined. Correct assignment of BIDs is left to the terrestrial network gurus; I just want them put in the appropriate place. JWW From : g0k8ka Title : UO-14 Whole Orbit Data Keywords : UO14 WOD TELEMETRY Uploader : G0K8KA Uploaded : Mon Jan 21 11:45:55 1991 __________________________ UoSAT SPACECRAFT DATA SHEET UNIVERSITY OF SURREY Guildford, Surrey GU2 5XH Tel: 0483-509143 FAX: 0483-34139 WOD ON THE UOSAT-3 PACSAT COMMUNICATIONS EXPERIMENT The PCE can conduct Whole Orbit Data surveys much like those supported by previous UoSAT onboard computers, but with some enhancements. The PCE Housekeeping Integration Task can sample up to 3 WOD surveys simultaneously, and the sample rate of a survey can be any value from 1 second upward. The PCE stores WOD and other information in an internal solid-state file store. WOD surveys are stored in binary files with Standard PACSAT File Headers (described in a separate document called PACSAT File Header Definition). As indicated in that document, the in the header of a UoSAT-format WOD file is 3. WOD files in the PCE file store are named using the following convention: wdMMDDNN wd - indicates that the file is a whole-orbit data file. MM - is replaced by a two digit month number, starting with 01 for January. DD - is replaced by a two digit day of the month. NN - is replaced by a two digit survey number, starting each day at 0. For example, the first whole orbit data survey taken on the 3rd of February will be in file a file named "wd020300". WOD files can be downloaded using the UoSAT-3 file server or received passively using the PACSAT Broadcast Protocol. These procedures are described in two documents: PACSAT Broadcast Protocol and PACSAT Protocol: File Transfer Level 0. BINARY FILE FORMAT Once a WOD file has been downloaded and its PACSAT file header removed, the file body contains a WOD survey in the standard binary format defined below. (Data structures are described in a C-like syntax defined in the document PACSAT Data Specification Standards.) All multi-byte values are stored least significant byte first. 'long' is 4 bytes 'int' is 2 bytes 'char' is 1 byte WOD files begin with a WOD_HEADER structure. WOD_HEADER { unsigned long start_time; unsigned long end_time; int sample_period; unsigned char number_of_channels; } The header is followed by the channel numbers, each one stored as an unsigned char (e.g. a single byte). is the start time of the WOD survey, an unsigned 32-bit binary integer counting the number of seconds since Jan 1 1970. is the ending time of the WOD survey, time encoded as above. is the number of seconds between samples in the survey. is an 8-bit unsigned binary integer telling how many channels were in the survey. The following bytes are the channel numbers themselves. This header is followed by the data samples from the survey. Each data sample contains channel values. The channel values are stored as unsigned 16-bit integers. Within each sample the channel values are in the same order as specified in the WOD_HEADER. That is, if the wod header says that channels 12, 13 and 22 are being sampled, each sample in the file will be three 16-bit integer values, the first from channel 12, the second from channel 13 and the third from channel 22. For example, here is the beginning of a survey taken on the UO-14 simulator, where the actual telemetry values have been replaced by their channel numbers (e.g. reading telemetry channel 1 always returns 1). The survey started at 0x26495e00, ended at 0x26495e78, was sampled every 0x0001 seconds, contained 0x04 channels and those channels were channels 01 02 03 and 04. The first two samples from the survey are then included. 00 5E 49 26 78 5E 49 26 01 00 04 01 02 03 04 01 00 02 00 03 00 04 00 01 00 02 00 03 00 04 00 From : g0k8ka Title : UO-14 Status Uploader : G0K8KA Uploaded : Tue Jan 22 14:30:15 1991 __________________________ ADDRESSING MAIL Mail for UoS should be addressed to "G0K8KA". JWW From : g0k8ka To : all Title : Status Report Keywords : UO3 FTL0 PB Uploader : G0K8KA Uploaded : Wed Apr 10 11:26:31 1991 __________________________ ** STATUS REPORT ** New features introduced during uploads (2/4, 3/4, 9/4, 10/4): BROADCAST PROTOCOL - Now reflect callsign of requesting station in the "OK" packet. The Broadcast Protocol implementation is still far from complete, and is nearing the top of the To Do list. FTL0 - Changes to activity log files to allow more detailed analysis of throughput. Log entries now mark the beginning and end of each "transaction", and count the number of bytes transferred during the transaction. Reception of an illegal FTL0 packet now causes immediate disconnect; the activity log will provide a reason for the disconnection. These errors are almost always an indication of data loss between your PC and TNC, look for the "BLOWOFF" indicator in the new alog display program output. (New alogdisp will be posted ASAP.) ERROR DETECTION AND CORRECTION - The RAMDISK is now being error washed on a regular basis; this should eliminate the already vanishing possibility that you will receive a file corrupted by radiation induced single event upset. The error log file, now called "eltlog" should reflect accurately the single event upset rate in the entire 4 Mbytes of RAMDISK space. A new version of the elogdisp.c program will be forthcoming. FURTHER UPLOADS - I hope that I will be able to retain files during future uploads, but this depends on the nature of the "crash" or whatever brings the system down. I am going to implement a "file system consistancy checker" to run before I warm start the file system; this will detect and correct simple problems like lost clusters or chains. If no major problems are found by this test, a warm start will be used, and files will not be lost. If major problems are detected, I'll have to cold start. Expect further uploads after I have time to work on the Broadcast Protocol, or when a fix comes through for the buffer loss problem which has slowly brought LUSAT and PACSAT to a halt. 73, JWW From : g0k8ka To : all Title : Memory Efficiency Keywords : UPLOADING LIFETIME Uploader : G0K8KA Uploaded : Mon May 13 18:57:00 1991 __________________________ When you are uploading a file and get interrupted by LOS or for some other reason, please try to CONTINUE THE UPLOAD. Don't start a new upload of the same file. If you abandon the partial upload and start fresh, you will leave behind a file fragment which takes up space in the file system and is no use to anyone. This is especially important for long files, where the fragment you leave behind can be the equivallent of several "normal" length messages. I just wanted to remind everyone that the partial files do sit around for a while (>7 days). Perhaps this time should be shorter? I'm not trying to discourage anyone from sending long files. UO-14 is a good way to relay the big ones; that's what it's here for. I'm just trying to encourage efficient operating practice. Right now (13 May), we are using UO-14's memory almost to its full capacity, and big fragments can force early removal of many small messages. The automatic removal algorithm tries to make sure that there is 500 kbytes of free disk space and 50 free directory entries. This automatic procedure has allowed us to have a hands-off maintainance system even without a "Kill" command. JWW From : g0k8ka To : all Title : Monitoring Activity Keywords : alogdisp Uploader : G0K8KA Uploaded : Thu May 23 11:05:07 1991 __________________________ Please monitor your own station's operation and not any anomolies that you observe regularly. This is the only way that we software developers can track down bugs and decide on the merits of enhanced features. If, for example, you attempt to download a message some 20 or more times, with the same undesirable consequences, please drop a message to the spacecraft software developer (G0K8KA) and the groundstation software developer (whoever that is). Using the activity log display program, you can see what your station did on the previous day. alogdisp al910522 pa3dvg would list pa3dvg's activities on the 22 of April. From the alog display you can begin to see if the satellite has a hard time hearing you or vice versa. Thank you in advance for your input, JWW From : g0k8ka To : all Title : alogdisp Uploader : G0K8KA Below are the results of some ALOG file analysis that I've been working on. For each day, I show the total number of seconds "session time" accumulated that day. Below, that time is broken down into 5 percentages. Idle - time when no command was being processed. This must be both a legitimate reflection of idleness and an artifact of the way that directories and selects are logged. Upload - time spent between the receipt of the upload command by the satellite and the completion of the final handshake. Down - time between the receipt of the download command and the completion of the final handshake. Dir - Time between receiving dir command and sending last data packet. (Note innaccuarcy here compared to download time.) Select - Time between receiving select command and sending sel response. If we ignore idle time for a moment, taking it as enevitable, then we see that downloads take the largest percentage of the satellite connected-mode activity, before and after the changes to the broadcast protocol. (This data looks good as vertically stacked bar graphs, with a bar per day. The bars are equal length (100%) and you can visually trace any changes.) JWW DATE 910410 910411 910412 910413 910414 910415 910416 Total 3098.0 3753.0 3258.0 5561.0 4915.0 4213.0 5128.0 % Idle 44.9 36.9 33.6 39.9 36.9 33.1 42.2 % Upload 10.6 1.8 10.0 4.8 6.6 .9 2.0 % Downlo 37.2 46.4 40.0 38.7 42.8 51.6 39.9 % Direct 6.1 13.6 14.6 14.3 11.5 12.8 13.3 % Select 1.2 1.4 1.8 2.4 2.2 1.6 2.6 DATE 910417 910418 910419 910420 910421 910422 910423 910424 Total 4543.0 4488.0 3832.0 7105.0 7449.0 5914.0 5837.0 7491.0 % Idle 43.2 40.6 36.5 49.1 37.2 35.5 40.1 45.0 % Upload 2.6 4.2 5.7 8.6 3.6 3.1 11.1 4.7 % Downlo 38.5 32.2 37.6 23.6 42.3 42.6 25.1 25.6 % Direct 13.9 20.1 16.7 16.0 14.1 15.1 19.0 20.5 % Select 1.9 3.0 3.5 2.7 2.8 3.7 4.6 4.2 DATE 910425 910426 910427 910428 910429 910430 910501 Total 7387.0 4124.0 5784.0 7353.0 6831.0 6583.0 7799.0 % Idle 43.3 35.0 39.3 38.4 37.2 31.0 33.1 % Upload 6.9 3.4 1.1 7.9 8.0 21.5 5.8 % Downlo 29.4 46.2 42.9 34.0 33.3 27.0 39.7 % Direct 16.5 12.7 13.0 15.7 17.7 16.3 17.8 % Select 4.0 2.7 3.7 3.9 3.8 4.2 3.5 DATE 910502 910503 910504 910505 910506 910507 910508 Total 4953.0 5391.0 8378.0 8667.0 6830.0 5146.0 3887.0 % Idle 26.9 26.1 29.2 37.3 35.2 33.4 46.3 % Upload 1.8 3.2 8.3 8.8 9.4 5.5 2.4 % Downlo 56.4 60.1 43.2 35.3 33.8 44.3 24.7 % Direct 12.4 7.7 16.4 15.2 18.2 12.8 21.0 % Select 2.5 2.9 3.0 3.5 3.4 4.0 5.6 DATE 910509 910510 910511 910512 910513 910514 910515 Total 6722.0 7483.0 8826.0 7702.0 4921.0 6583.0 7047.0 % Idle 35.9 39.1 31.7 34.4 31.1 32.9 38.4 % Upload 7.0 5.0 21.7 5.6 12.4 13.7 8.3 % Downlo 38.1 34.0 24.4 38.7 38.6 34.3 28.0 % Direct 14.6 15.6 18.2 17.4 12.9 14.0 19.8 % Select 4.4 6.3 4.1 4.0 5.0 5.1 5.5 DATE 910516 910517 910518 910519 910520 910521 910522 Total 5454.0 6015.0 9694.0 7155.0 9825.0 7181.0 6573.0 % Idle 33.2 38.3 38.6 31.8 49.6 48.5 32.6 % Upload 2.6 4.0 4.2 2.9 4.7 1.1 12.4 % Downlo 44.2 35.5 36.9 50.0 18.8 17.6 39.1 % Direct 14.7 17.9 16.9 12.1 22.6 27.7 12.4 % Select 5.2 4.2 3.5 3.2 4.3 5.0 3.6 JWW From : g0k8ka To : all Keywords : SEU F6FBB Uploaded : Fri May 24 10:32:05 1991 __________________________ The "uncorrectable SEU" means that somewhere in a file, more than 2 bytes were corrupted in a single 256-byte block. If you download the file after this, you will always get a checksum error when extracting the header. On text files, this is not much of a problem, but on .zip or other binary files, it makes them useles. Uncorrectable SEUs are very rare; out of the 1267 SEUs which have been corrected since the 9 April reload, only 7 have been uncorrectable. Files 1550, 176e, 1653 and 4 unidentified files were effected. We'll try to improve this by speeding up the wash rate. You can keep track if this yourself by looking at the eltlog file with the program elogdisp. Look for SEVERE errors, as these are the ones which couldn't be corrected. I'm glad that people are using the system to transfer big files, and would like to encourage experimentation (voice, fax, images ...). JWW From : g0k8ka To : all Title : PB tx delay Uploaded : Sat May 25 10:04:32 1991 __________________________ WB9MJN indicates that when he starts PB, it doesn't go into full duplex mode and the TX delay doesn't get set. (The symptom of the TNC not being in full duplex mode is that it must wait for your DCD line to flicker before it will send your broadcast request packets.) I think that this problem (which we had in the UoS control station as well) is caused by lack of appropriate delay between putting the TNC in KISS mode and sending the full-duplex and TX delay commands. If the TNC is still busy flashing the STA and CON lights then it misses the commands. A cure for this has been available in PB for some time: restart_delay 60 in your PG.CFG file will cause PB to delay 3 seconds before and after putting the TNC into KISS mode. The txd and fulldup commands should now be accepted correctly. You should see the commands be sent to the TNC as a brief flicker on STA after CON and STA have finished their blinking. JWW From : g0k8ka To : g3rwl Title : PG/PB Suggestions Keywords : PG PB Uploader : G0K8KA Uploaded : Wed Jun 05 14:52:47 1991 __________________________ Richard, Thanks for the observations r.e. PG and PB. In order 1) Auto detection of "OK" packets: Eventually, I'll put that in, but I suspect that it will generate a lot of automatic rubbish on the uplink. I'm also going to have a periodic beacon telling what stations' requests are still in the broadcast rotation being serviced. 2) Message editor: If I do this, it will be a shell to DOS or shell to your favourite editor (like Procomm does). I don't want to write even a simple editor myself. Of couse, there is no need to force a disconnect while viewing/composing mail, since the default state for PG is disconnected. Combined PG/PB would indeed be desirable, but can only be done well if I use an AX.25 implementation running on the PC, with the TNC only acting in KISS mode. Any suggestions as to a source of full featured TSR or linkable "software TNC" will be accepted. The BPQ code isn't flexible enough for this particular task, since it thinks it's a 'node' with all the attendant peculiarities. I can't honestly see this task coming up the list until next year, though. Perhaps by then someone else will have done it. (In fact, PE1CHL has already done it for NET users.) 3) MCON ON - Frightning. With TAPR TNC firmware there is no reliable way to separate connected-mode data to me from monitored data - certainly not in the face of a full binary link. This would only become possible when using a KISS TNC and software AX.25 on the PC, as above. 4) PgUp/PgDn implementation. I could have some overlap, but once you know that nothing is missed, this becomes a non problem, doesn't it? 5) The spacecraft software includes selective directories, but no attempt has been made to impelement them in PG. I'll probably look at some useful new SELECTs this summer in conjunction with a BBS forwarding release of PG. Frankly, since connected mode should only be used for uploading, you shouldn't worry about 'clogging the system'. It's all the people still using connected mode for downloading who should worry. 6) More elegant program exit. Hmm. I exit through the standard Microsoft C exit function and program shutdown code. In fact, after I got your message, I checked that both PG and PB could be used in batch files. I had success here, and can't see what your difficulty is. Drop me one of your menu files and let me play around with it. (Nev thought your problem could have comething to do with FILES= in config.sys.) 7) The file directory is in date order. The file date is set when the file is completely uploaded, or in the case of on-board files (ALxxxx, CPxxxx, WDxxxx, and ELTLOG), when the file is "posted" by the generating program. As far as I can tell, date order is the only useful order for the directory, since is assures that you will see files when they are really "new". Consider the eltlog - it would always be the lowest file in the directory if files were sorted by number. Or, worse, if I start uploading a file on Friday, but don't finish it, it clearly can't show up in your directory yet. Then I complete the file Monday, but it shows up in numerical order, e.g. you'll probably miss it because of the 40 files uploaded over the weekend. The "elegant", "truely sequential" order - e.g. file number order - is not really representative of reality. File numbers are just handles for the files. Thanks for the input, and I'm glad to see you active on the system. The UoSAT-2 bulletins are also appreciated. JWW From : g0k8ka To : all Title : NO -1 & NO -2 Uploader : G0K8KA Uploaded : Thu Jul 18 22:47:15 1991 __________________________ I'm sorry I forgot to tell you all before: NO -2 means file not found. File has been deleted. NO -1 means broadcast queue full. Most people have probably already figured it out, but I wanted to document it just in case. JWW From : g0k8ka To : wb7qkk Title : ;) Means ... Keywords : PG CON TNC Uploader : G0K8KA Uploaded : Tue Nov 12 12:37:27 1991 __________________________ Bill The message ;) indicates that your TNC is not informing your PC that you are connected to the satellite. This generally means that you don't have the connect line hooked between TNC and PC. It may also indicate that the TNC asynch port does not have the connect status on the DCD pin. This is pin 1 on the DB-9 connector. What I can't understand is how you are able to work on UO-14. I suspect that you must use a different TNC and a different RS-232 cable. Jeff From : g0k8ka To : all Title : No evidence Uploader : G0K8KA Uploaded : Sun Nov 17 11:44:53 1991 __________________________ Please. It's time for everyone to stop speculating about the UO-14 uplink "problems" over Europe. There is no technical evidence to suggest that any station which uses the UO-14 BBS is responsible for the super strong signal on the uplink. Those of you who listened at 1015 on Saturday morning will have heard exactly what was on the uplink, when I threw it into analogue repeater mode toward the end of the pass. I made out: (1) no FSK modulation on the signal (2) generally no intelligence on the signal (3) some tones which sounded like access tones for terrestrial repeaters (4) at least one burst of full quieting FM voice in Spanish or Italian Instead of trying to find and identify the interfering source by suspecting those who actually use the satellite to communicate, why not try to map out the extent of excessive signal strength on the RX1 RSI channel of UO-3's telemetry. Excessive means anything approaching or exceeding 4 volts. ON THE BIG UPLOAD TOPIC If we want to use UO-3 to send large files, then there are going to be some large uploads. The stations making these large uploads are going to attract attention, but we are playing a "zero sum game". If it takes N minutes of link time to uplink the message, those N minutes can't be used by other stations for other purposes. I think that it is reasonable to ask for these uplinks to be broken every couple of minutes, but this is purely a personal point of view, and can't really be backed up by a technical argument. My view of the satellite is that if you can get one directory in the morning and one in the evening then the system works. When the broadcast directory is in place, this will not be a problem. But we shouldn't waste too much time ringing our hands over the current situation; the system works - more than 50 messages a day are uploaded by 150 active stations. JWW P.S. - To those who have been accused: thanks for staying calm. If you get really angry, write a letter and send it in the post, or make a phone call. Let's try not to let UO-3 degenerate into what's worst about terrestrial packet. From : db2os To : g0k8ka,all Title : New PB, some hints Keywords : PB Uploader : DB2OS Uploaded : Sat Dec 21 18:39:38 1991 __________________________ PG 21/12/91 15:00utc Hello Jeff and Users! New PB works excellent! some small bugs found: 1) txdelay Initial value of 150ms in the .cfg file seems to be too long. txd 50 should sufficient on UO-14 with most transceivers (for UO-22 I need txd 70). Users: Please keep the TXDELAY as short as possible. All in all, a very nice program and I now see more 'open' messages on the screen.. :-) Let's start uploading many nice Christmas Greetings for Jeff and all at UoS! 73s Peter DB2OS * MERRY CHRISTMAS and a happy NEW YEAR * From : wa2lqq To : all Title : Dir Problem Symptoms Keywords : PB Shutdown Problem? Uploader : WA2LQQ Uploaded : Fri Dec 27 03:57:24 1991 __________________________ 0300UTC 27Dec91 Greetings from another one who has current problems with PB. As others have here noted, there are problems with losing the directory display. Let me add a few symptoms to the pile so far amassed. I am NOT implementing any Block file type via .CFG yet have experienced the same problem as others. So I think I would rule out file blocking as a cause. Moreover, I let PB run for a couple of days without exiting to DOS and everything continued to work fine with PB. The directory filled and was maintained normally. THEN, however, the very first time I exited to DOS and then returned to PB, the directory was fouled up in the "usual" way, i.e., entries from the 25th on were missing. My suspicion leans towards the PB shudown mechanism. Perhaps the PFHDIR.PFH file is not put to disk properly. Perhaps once the file gets too large (equating to about 25Dec from the start point) it can no longer be logged in the proper manner. Or more likely, perhaps once it reaches a certain size, it cannot be recalled properly because of the way it was recorded upon shutdown. (I recall someone said the directory actually was on disk; it just was not being recalled and displayed properly. Again, my central thesis is that the problem is not associated with Blockftype, but rather in the PB shydown procedure. My evidence is in repeatable experiments performed here since the problem first manifested, i.e., if you leave PB running, it has no problems. But, if you exit from PB to read a logged message, you'll find the directory problem upon restarting PB. So that's my input. "Neeeeeeeext!" 73 Rip From : ja6ftl To : All,PB Title : Vanishing directory Keywords : PB problem Uploader : JA6FTL Uploaded : Fri Dec 27 01:12:29 1991 __________________________ Peter notified that block type 12 disturb captureing directory bcst. But my experience this night was different. After directory trouble, I deleted the all related file and capture again from the first. This time my configuration was blockftype 2 blockftype 5 blockftype 99 blockftype 11 blockftype 12 ; There was no inconvenience and directory list was completed. After reading Peter's note, I edit PB.CFG and comented out "blocktype 12" line. I re-start PB, resulted ... All directory dated 25 vanished never to reappear! It seemed any block type itself is NOT trouble maker but renewing PB.CFG file is the cause of my trouble. Take care about editing PB.CFG DIRECTORY BUG CURE !!!!! ~~~~~~~~~~~~~~~~~~~~~~~~ I wanted to pass my changes to PFH first to Rob PE1CHL, rather than upload a variant to confuse things, but the recent problems with PFHDIR.PFH "losing" new entries prompted me to upload a MSDOS version that can "fix" a damaged directory created by the new 911221 PB.EXE. I also include a diff file showing where I have made changes to the PFH 1.2d base code. So, to recover whatever is possible from a damaged PFHDIR.PFH, issue this command: pfh -cs pfhfir.pfh The damaged directories seem to have a sequence of good headers, followed by a partial header that lacks the proper AA55 introduction. PB seems to stop its header scan at this point while starting up, but pb can find newly-acquired dir entries. When PB is exited, the new entries are written after the malformed entry, leading to their "loss" when PB is invoked again. I changed PFH to discard invalid header pieces so as to re-sync at the next valid header (having an AA55 introducer). This seems to recover much of the lost data. Also, I have seen no problems with compatibility with SLIST.DAT. Perhaps I've been lucky? One more point: PFH can display the directory (use the -d option). The grab/priority/auto/never flags are apparently stored in SLIST.DAT, which is not processed by pfh. Do let me know if you find a problem with this fix method. I suppose it is no worse that starting over! 73 & season's greeting, de James N5KNX From : nk6k To : all Title : "not a jpeg" explained. Keywords : jpg jpeg Uploader : NK6K Uploaded : Sat Jan 04 06:50:36 1992 __________________________ Not a JPEG file If you don't use the -j option when you use gif2jpg, you can't view the resulting file with some versions(all?) of alchemy. I've also had trouble displaying Macbinary built files with the 1.3 version of alchemy, the 1.4 version does better. If you are using gif2jpg, use the -j option to make the most portable file. Harold. From : g0k8ka To : all Title : UO-14 Status (Thursday) Uploader : G0K8KA Uploaded : Thu Jan 16 09:26:10 1992 __________________________ UO-14 Status (Thursday 16 January) The tests of UO-14 on the non-amateur frequencies are going well, and I expect that we will be able to restore full operation to the amateur frequencies on Friday A.M. UTC. There is even some sign that we are closing in on the underlying software bug. Thank you all for your cooperation; I do understand that some automated stations will have transmitted "without human collaboration" and that's not a major problem. Because of the shortage of memory on UO-14 and the relative glut of memory on UO-22, we may make some changes to satellite usage in the amateur service soon. Translation? "Check out your station's operation on UO-22 to prepare for changes." JWW From : g0k8ka To : all Title : UO-14 News Keywords : UO-14 PB FTL0 Uploader : G0K8KA Uploaded : Fri Jan 24 10:59:31 1992 __________________________ ** Watch the Downlink ** The downlink of UO-14 is its "general beacon." Messages on the downlink indicate what state the satellite is in, and what operations you can expect to succeed at. On Wednesday, I had to unload the FTL0 server to investigate the loss of 1.8 MBytes of RAMDISK space. I unloaded FTL0, loaded a program to peek the File Access Table (FAT) and Directory area of the RAMDISK, and downloaded the peek file. Then I used a ground program to analyse the FAT and Dir. I found the lost clusters, and on Thursday reloaded UO-14 with a special file system to recover the clusters. During this operation, there was no FTL0 server, and so PG would not work. This is easy to detect: there were no BBSTAT packets on the downlink. No BBSTAT = no FTL0 = no PG and no uploading. ** Automatic File Delete Times ** From Thursday, I have modified FTL0 to examine what you put in the EXPIRE_TIME field of an uploaded message. [Users of pfhadd.exe don't have a way to alter this yet, so can ignore this matter.] If your EXPIRE_TIME is in less than four days from the completion of your upload, then it will be used instead of the system default. If your EXPIRE_TIME is greater than four days from the completion of your upload, or EXPIRE_TIME is 0, then your message will become "deleteable" in 4 days. Partial messages will be deleted 36 hours after they are created, if you do not complete the upload. These measures should help relieve the congestion on UO-14. I encourage you to use a short EXPIRE_TIME if you know that the station you are communicating with can be trusted to download its mail in less than 4 days. If everyone uses this feature sensibly, then I may bump the system default to 7 days so that keplerian elements and bulletins are kept for one week. From : g0k8ka To : w0sl Title : Old answers Uploader : G0K8KA Uploaded : Wed Jan 29 20:03:03 1992 __________________________ Roy, Just to answer a couple of outstanding queries: It is likely that you will get an error (e increment) when you go to the directory view or do anything which could (A) occupy the CPU for more than (4000*8)/9600 seconds (B) turn off the interrupts for more than 8/9600 seconds I wouldn't worry about it! JWW From : g0k8ka To : all Title : Move over to UO-22 Keywords : UO-3 UO-22 NEWS Uploader : G0K8KA Uploaded : Tue Feb 04 00:21:00 1992 __________________________ *** Amateur Radio Operations Move from UoSAT-3 to UoSAT-OSCAR-22 *** 3 February 1992 University of Surrey In late December, we introduced an enhanced broadcast server on UoSAT-3, which did a lot to reduce congestion on the satellite's single uplink; now we have another bottle-neck. Because UoSAT-3 has only 256 kBytes of program/data memory, we are using a RAMDISK which can only hold 400 messages at a time; with uplink contention reduced, gateways on line, and more than 150 stations regularly active, this 400 message limit is often exceeded. When the satellite is full, new messages cannot be uploaded, and older messages have short lifetimes (before being deleted automatically to make way for new messages). The large population of amateur radio stations on UoSAT-3 is also somewhat limiting for the non-amateur stations which get only very small access windows (roughly 1:5 of the opportunity given to amateur stations). The brief bursts of transmission on the non-amateur downlink interrupt amateur activity and also make it difficult for automatic frequency control circuits to operate on the non-amateur downlink. In addition to UoSAT-3 (OSCAR-14) the controllers at Surrey have UoSAT-5 (OSCAR-22) as a potential resource. SatelLife - the organisation which paid for most of UoSAT-5 - had planned to operate the satellite predominantly on non-amateur frequencies. Operation of the CCD camera on the amateur downlink was to be a "secondary" activity of UoSAT-5. After launch, this plan has run into two difficulties: The UoSAT-5 CCD camera has proven very successful, and amateur radio stations around the world are downloading the images of the Earth; images are taken several times per week, and each is more than 300 kbytes of data. Furthermore, UoSAT-5's high power amplifier which has produced excellent output on the amateur frequencies - does not work reliably on the non-amateur frequencies. Taking into account the resources available to us and our obligations to SatelLife and other organisations, we have decided to take the following steps to optimise our use of UoSAT-3 and UoSAT-OSCAR-22: 1) All non-amateur traffic, both SatelLife and VITA will be carried on UoSAT-3, which will cease to transmit on its amateur downlink. 2) All amateur traffic will move to UoSAT-OSCAR-22, and UoSAT-OSCAR-22 will operate as a dedicated amateur radio satellite transmitting constantly on its amateur downlink. Of course, there is a price to pay for this transition: Most notably, the conflict between CCD users who want to download large CCD image files and "BBS" users who just want to get their mail. We are looking into on-board JPEG compression for the images, and this potential disadvantage will be balanced by the following advantages: - 512kBytes of program memory permitting 800 message capacity - two amateur-radio uplinks : 145.900 and 145.975 - no downlink frequency switching (permanently on 435.120) ** THE BIG SWITCH ** The UO-22 file server is now enabled, and we recommend that all new messages be uploaded to UO-22 and not to UoSAT-3. The UoSAT-3 FTL0 server will be disabled sometime on Wednesday, February 5, and UoSAT-3's amateur downlink will be turned off. I apologize for the short notice, but there is engineering work on UO-3 which must be done this week, and there hasn't been enought time for a more gradual transition to be publicised. Jeff Ward G0/K8KA University of Surrey Spacecraft Engineering Research Unit